home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc660.txt < prev    next >
Text File  |  1994-08-01  |  5KB  |  116 lines
  1. Network Working Group                                       D. Walden (BBN-NET)
  2. Request for Comments: 660                                              Oct 1974
  3. NIC #31202
  4.  
  5.  
  6.        SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE
  7.  
  8. In the next few weeks several changes will be made to the IMP
  9. software including changes to the IMP/Host software interface
  10. as specified in BBN Report No. 1822, Specifications for the
  11. Interconnection of a Host and an IMP. These changes come in
  12. four areas: a) decoupling of the message number sequences of
  13. Hosts; b) Host/Host access control; c) expansion of the
  14. message number window from four to eight; and d) provision for
  15. messages outside the normal message number mechanism. All changes
  16. are backward compatible with possible minor exceptions in timing.
  17.  
  18. a. Decoupling of the Host/Host message number sequences:
  19.    Since 1972 the IMP system has provided for exactly four
  20.    messages to be outstanding at a time between any pair of
  21.    IMPs, and thus, a total of only four messages between
  22.    all the possible pairs of Hosts on the two IMPs. Because
  23.    all the pairs of Hosts on the two IMPs have had to share
  24.    the four outstanding messages, it has been quite possible
  25.    for the various Hosts to interfere with each other. To
  26.    remove this possibility of interference, the IMP's
  27.    message number logic will soon be changed to allow a
  28.    separate message number sequence between each pair of Hosts.
  29.  
  30.    To keep manageable the space required to maintain the
  31.    Host/Host message sequences above that presently are required
  32.    for the IMP/IMP message sequences, the Host/Host sequences
  33.    will be taken dynamically from a limited pool of possible
  34.    sequences. The pool will be sufficiently large to seldom
  35.    interfere with a pair of Hosts wishing to communicate. In
  36.    no case will Hosts be prevented from communicating. In
  37.    the event that the Hosts on an IMP desire to simultaneously
  38.    communicate with so many other Hosts that the pool would
  39.    be exhausted, the space in the pool is quickly multiplexed
  40.    in time among all the desired Host/Host conversations
  41.    so that none is stopped although all are possibly slowed.
  42.  
  43. b. Host/Host access control:
  44.    Upon instructions from ARPA, we will soon add a Host/Host
  45.    access control mechanism to the IMPs. Any pair of Hosts
  46.    wishing to communicate is checked (via bits in the IMP)
  47.    to verify that they have administrative permission to
  48.    communicate. This check normally is made whenever a pair
  49.    of Hosts attempts to communicate after not having
  50.    communicated for two minutes. If the pair of Hosts is
  51.    not allowed to communicate, a special type of Destination
  52.    Dead Message (sub-code 3) is returned to the source
  53.    Host. The default case initially will be to allow all
  54.    Hosts to communicate with each other.
  55.  
  56.  
  57.  
  58.                               -1-
  59.  
  60.  
  61. c. Message number window.:
  62.    Once the message number sequences are on a Host/Host
  63.    rather than IMP/IMP basis, the number of messages that
  64.    will be permitted to be outstanding at a time between
  65.    a pair of Hosts will be expanded from four to eight,
  66.    permitting increased Host/Host throughput in some cases.
  67.  
  68. d. Message outside the normal mechanism:.
  69.    For certain limited experiments which are being carried on
  70.    using the network, it is thought to be desirable
  71.    for specified Hosts to be able to communicate outside the
  72.    normal ordered, error controlled message sequences.
  73.    Thus, the following expansion to the IMP/Host protocol is being
  74.    provided.
  75.  
  76. i. a single packet message coming from the source Host
  77.    to the source IMP with a (new) special message type,
  78.    3, will be put directly into the IMP store-and-forward
  79.    logic with a mark saying the packet is this special
  80.    kind of message. A multi-packet message of type 3
  81.    will be discarded.
  82.  
  83. ii. such messages (packets) are routed normally to the
  84.    destination IMP, possibly arriving out of order.
  85.  
  86. iii. at the destination IMP, messages of the special
  87.    type will be put directly on the destination Host
  88.    output queue skipping the reassembly logic and marked
  89.    with a special (new) IMP to Host message type, also 3.
  90.  
  91. iv. there is no source-to-destination retransmission
  92.    logic, no reassembly, no RFNMs, no incomplete
  93.    transmissions, etc.
  94.  
  95. v. if at any time there are insufficient resources in the
  96.    network to handle one of these special messages
  97.    (e.g., the destination Host won't take it), the
  98.    message will be discarded.
  99.  
  100. vi. by using the special message type between the Host
  101.    and the IMP, the normal message number mechanism is
  102.    preserved for all the Host/Host transmissions which
  103.    presently depend on it.
  104.  
  105. Because the uncontrolled use of this mechanism will degrade the
  106. performance of the network for all users, the set of Hosts permitted
  107. to use this mechanism will be regulated by the Network Control
  108. Center.
  109.  
  110. Please file this note with your copy of BBN Report 1822 until
  111. that document is updated.
  112.  
  113.  
  114.  
  115.                               -2-
  116.